AMENDMENTS TO THE SPECIFICATION: 



Please replace the paragraph beginning on page 2, line 8 with the following: 

In the hardware design (or H/W design), elements sourc e s having equivalent 
functions of the algorithms are generally described b y equivalent HDL source code fwhich 
stands for 'Hardware Description Language'), then, composition of circuitry is carried out 
(see step B3). In step B4, verification is made as to whether the sources operate correct 
normally or not. In the software design (or S/W design), elements sourc e s having equivalent 
functions of the algorithms are generally described by equivalent source code of a fee 
programming language having a CPU dependency (see step B5). In step B6, verification is 
made as to whether the sources operate correct n ormally or not. Lastly, cooperative 
verification is performed on combinations of the hardware and software (see step B7). 

Please replace the paragraph beginning on page 2, line 23 with the following: 

Due to rapid increases in scales of integrated circuits being manufactured in 
these days, it becomes necessary to provide considerably large numbers of lines of codes fef 
us e in d e scription o f to describe the circuits to be created. This causes considerable reduction 
in simulation speed of the cooperative verification on descriptions using the HDL or other 
programming languages each having a CPU dependency. In practice, it becomes very 
difficult to perform the architecture design using the cooperative verification. 

Please replace the paragraph beginning on page 3, line 5, with the following: 

In the architecture design using the cooperative verification, there may occur 
necessities of modifications on buses interconnecting said elements to be implemented in 
b e twe e n the hardware and /or in software due to results of evaluation of performances of the 
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buses. In that case, it is necessary to modify the HDL or other programming languages each 
having a CPU dependency (see steps B8, B9 in FIG. 1 1). 

Please replace the paragraph beginning on page 3, line 10, with the following: 

Due to increasing numbers of lines of codes to describe for us e in d e scription 
e£the circuits to be created, circuit descriptions must become more and more complicated, 
which in turn cause complexity complicity in modifications of the circuit descriptions. That 
is, it takes much time and cost to perform operations regarding feedback loops being derived 
from results of the cooperative verification. Recently, there are tendencies in which periods 
for developments of LSI are considerably reduced while the circuit scales are increased more 
and more. To cope with such tendencies, the procedures of the LSI design and development 
should meet some essential conditions in which evaluation of performances of the buses 
interconnecting elements to be implemented in b e tw ee n th e hardware and /or in software and 
the architecture design are performed at high-level stages of design respectively. 

Please replace the paragraph bridging pages 3 and 4 with the following paragraph: 
It is an object of the invention to provide a bus performance evaluation method 
for algorithm description by which it is possible to considerably reduce turnaround times in 
design of LSI by excluding unwanted operations regarding feedback loops derived from 
cooperative verification in the hardware design and software design. According to an aspect 
of the invention, these provide a method as defined in independent claim 1. Basically, this 
invention provides improvements in procedures for the design and development of LSI. That 
is, after isolation of the hardware and software being effected with respect to sources 
described by the general purpose high-level language in algorithm design, an evaluation 
function is created to count traffic of the bus interconnecting elements to be implemented in 
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b e tween th e hardware and /or in software. The sources are modified such that the evaluation 
function is performed every time data (e.g., a variable) is loaded onto the bus. Then, 
evaluation is performed on the performance of the bus having a processing rate. Based on the 
bus traffic that is finally produced with respect to the processing rate, isolation of the 
hardware and software is optimally performed at the prescribed stage of the architecture 
design. Thus, it is possible to exclude the feedback loops regarding the isolation between the 
hardware and software from the cooperative verification after the actual coding. As a result, it 
is possible to considerably reduce the turnaround time in the design of LSI. 

Please replace the paragraph bridging pages 3 and 4 with the following paragraph: 

More specifically, the LSI design and developmen t process comprises » 
manufactur e is actualiz e d by algorithm design, architecture design, actual hardware and 
software design, and verification. Herein, the architecture design contains a simulation 
platform simulation program structuring process and a bus performance evaluation process, 
which are interconnected by a feedback loop. In the algorithm design, sources are described 
by the general purpose high-level language such as the C language and C++ language. In the 
simulation platform s imulation program structuring process, the sources are subjected to 
isolation of the hardware and software, while an evaluation function is created to count bus 
traffic of the bus interconnecting between the hardware and software. Every time data is 
written to a pre-defined variable loaded onto the bus, the evaluation function is performed to 
modify the sources. Then, evaluation is performed on the performance of the bus, so that the 
bus traffic for its processing rate is finally produced. That is, result of the bus performance 
evaluation process is fed back to the simulation platform simulation program structuring 
process such that isolation of the hardware and software is optimized in response to the bus 
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traffic for the processing rate of the bus. This results in exclusion of feedback loops derived 
from the cooperative verification after the actual coding, so it is possible to considerably 
reduce overall turnaround time of design. 

Please replace the paragraph beginning on page 5, line 17 with the following: 

FIG. 4 is a flowchart showing procedures of works that are effected by the first 
embodiment shown in FIG. 2; 

Please replace the paragraphs beginning on page 6, line 12 with the following: 
FIG. 1 shows a flow of procedures for design and development of LSI in 
accordance with the invention. As compared with the conventional flow of procedures for the 
LSI design and development that is described in conjunction with FIG. 1 1, the present flow 
shown in FIG. 1 provides is facilitat e d in manufactur e to e nabl e t he architecture design at the 
high-level stage of design and is characterized by adding a simulation platform simulation 
program structuring process and a bus performance evaluation process (see step A15). 
Details of these processes will be described below. 

Please replace the paragraphs beginning on page 6, line 19 with the following: 

In step Al, algorithms are designed to be implemented in fe p-logic circuits, 
devices and systems to be manufactured. In step A2, verification is made as to whether the 
algorithms are made correctly or not. 

Please replace the paragraph beginning on page 7, line 11 with the following: 

Next, evaluation is performed on the performance of the bus, which is a subject 
of evaluation, by using the structured simulation platform simulation program . That is, in the 
performance evaluation process, the flow proceeds to step A7 in which verification is 
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performed using the structured simulation platform simulation program . In step A8 5 bus 
traffic is calculated by the prescribed method, which depends on the created evaluation 
function. Herein, a processing rate requested by a main function is provided, alr e ady known. 
Hence, the bus traffic is calculated with respect to the processing rate of the evaluated bus in 
step A9. 

Please replace the paragraph beginning on page 8, line 19 with the following: 

FIG. 2 shows a list form representing a bus performance evaluation method in 
accordance with the first embodiment of the invention. With reference to FIG. 2, there are 
provided three variables, namely 'a', 'b' and V being loaded onto the evaluated bus, wherein 
all of the variables are subjected to global definition. In addition, there are provided an 
evaluation function 4 BUS0()' and a local variable 'busO\ Herein, the evaluation function 
increments a static variable i to provide a return value. The local variable busO stores the 
return value from the evaluation function BUS0(). Namely, it represents a number of times in 
effecting data transfer on the evaluated bus. The same number of bits are set to binary 
representations of the three variables a, b, c being loaded onto the evaluated bus. Herein, the 
number of bits of each variable is smaller than the number of bit lines (or bits) of the 
evaluated bus. 

Please replace the paragraph beginning on page 11, line 19 with the following: 
FIG. 5 shows the bus performance evaluation method of the second 
embodiment that has three fr ee-variables a, b and c, which are loaded on the evaluated bus and 
all of which are locally defined. In addition, there are provided an evaluation function 
BUS0() and a local variable busO(). The evaluation function increments a static variable i to 
provide a return value. The local variable busO() stores the return value from the evaluation 
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function BUS0(). That is, it represents a number of times in effecting data transfer on the 
evaluated bus. 

Please replace the paragraph beginning on page 13, line 22, with the following: 

In the aforementioned case, when data are written to the variables loaded onto 
the evaluated bus, data transfer is effected on the bus multiple times, a number of which is 
calculated by 'n/m', that is, four times. To perform the performance evaluation on the bus, 
bus traffic for its processing rate is calculated by the following equation (2). 
(Bus traffic for the processing rate) 

= (number of times in execution) x [[4 ]] (n/m) / (processing rate) ... (2) 
Next, further embodiments of the invention will be described with reference to 
Figures 7 to 10 

Please replace the paragraph beginning on page 14, line 17 with the following: 
Different from the foregoing first embodiment of FIG. 2, the fourth 
embodiment of FIG. 7 deals with two variables bits-loaded onto the evaluated bus, wherein 
the two variables are configured by different numbers of bits, both of which are greater than 
the number of bits of the evaluated bus. In addition, the fourth embodiment of FIG. 7 is 
characterized by that the evaluation function having two arguments 'bit' and 'bus', and it 
increments the static variable i to provide a return value. To perform performance evaluation 
on the bus, bus traffic for its processing rate is calculated by the aforementioned equation (1). 
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Please replace the paragraph beginning on page 15, line 14 with the following 
paragraph: 

Both of the variables a, b loaded onto the evaluated bus consist of the same 
number of bits, which is smaller than the a number of bits of the evaluated bus. Different 
from the first embodiment of FIG. 2, the fifth embodiment of FIG. 8 is designed such that 
both of the variables loaded onto the evaluated bus are defined by specific arrays, and address 
transfer is effected in the main function. In addition, the fifth embodiment is characterized by 
that the evaluation function having an argument 'ele' increments the static variable i by 'ele' 
to provide a return value. 

Please replace the paragraph beginning on page 18, line 19 continuing through 
pages 20 with the following paragraph: 

As described heretofore, this invention has a variety of effects and technical 
features, which will be described below. 

1 . When data are written to variables loaded onto the evaluated bus, sources that are 
described by the general purpose high-level language such as the C language and 
C++ language for use in the algorithm design are modified by executing a specific 
evaluation function for increment by a certain value, so that a simulation 
platform simulation program is structured. Hence, bus traffic is calculated in 
connection with the processing rate of the bus interconnecting between the hardware 
and software, so bus performance evaluation can be performed at the high-level stage 
of design in the LSI design and development. In addition, result of performance 
evaluation of the bus is fed back to structuring of the simulation platform simulation 
program , so it is possible to perform the architecture design at the high-level stage of 
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design. Because the architecture design is performed using the sources that are 
described by the general purpose high-level language for use in the algorithm design, 
it is possible to considerably reduce overall simulation time for the architecture 
design. Generally speaking, as compared with the HDL, the C language and C++ 
language are increased in simulation speed to be approximately one-thousand times 
higher. 

2. Because the architecture design is performed using the sources that are described by 
the general purpose high-level language, it is possible to simplify feedback 
procedures due to the architecture design. By optimally performing isolation of the 
hardware and software at the prescribed stage of the architecture design, it is possible 
to exclude feedback loops regarding the isolation of the hardware and software from 
the cooperative verification after the actual coding. This guarantees considerable 
reduction of the turnaround time of design. As compared with the HDL and e&er 
assembly languages, the C languag e and C++ language can b e used relative d e scrib e d 
using a r e lativ e ly small number of lines of codes. That is, those languages can be 
easily changed and modified according to needs. 

3. This invention places the cooperative verification on unification of the hardware and 
software as one type of simulation for merely performing operational confirmation, wherein 
no design is newly performed. This brings exclusion of the feedback loops being derived 
from the cooperative verification. That is, it is possible to reduce a number of times in 
effecting simulation in RTL (Register Transfer Level) , so it is possible to considerably reduce 
overall time and cost for 
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the design of circuitry. Such an effect becomes substantial as the scale of circuitry being 
manufactured increases. 

Please replace the paragraph beginning on page 20, line 4, with the following 
paragraph: 

As this invention may be embodied in several forms without departing from 
th e teaching spirit of essential characteristics thereof, the present embodiments are therefore 
illustrative and not restrictive, since the scope of the invention is defined by the appended 
claims rather than by the description preceding them, and all changes that fall within metes 
and bounds of the claims, or equivalence of such metes and bounds are therefore intended to 
be embraced by the claims. 
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